Conversation
It's been almost 6 years since the feature was disabled due to instability running GDBM tests in commit 229e23b. The original intent in the commit which introduced the ASAN CI job was described in commit 4e4a36d "Whilst this *will* detect various dangerous mistakes involving bad memory accesses, it's far more likely to spot if changes create memory leaks." I think it is time to revisit to see after many tooling releases if LeakSanitizer is choking. If so, perhaps it would be better to remove GDBM install as part of this job until whatever triggers failures can be identified and fixed rather than limiting ASAN features in an ASAN CI job.
|
In the logs from the CI run here on Ubuntu 24.04, I see |
|
Same error is observed on Ubuntu 26.04 in the logs from PR #24767 |
|
The logs from the run on 26.04 shed a little more light. |
|
In PR #24767, I skipped installing libgdbm and libdb, and the LeakSanitizer error is still there. Seems like it's always when it comes to running the |
|
I think we need to re-run the CI a few times to check if the (intermittent) GDBM errors are fixed. |
Unfortunately I can only restart one sub-job at a time. In future re-runs I'll just re-run all CI. |
It might be a better idea to enable debugging on the sanitizer and let the CI re-run to see what is upsetting it exactly. |
|
|
Ahh, sorry, I missed the failed run on the other ticket. Unfortunately setting the verbosity on means the run fails due to the build log being too large, so we don't get any useful information from it. If this is flaky enough that your tests showed failures I don't think we can enable it. Note that we do get full ASAN runs from volunteer daily build reports, eg. see this. Maybe I'll add ASAN to another configuration for my runs. |
3 participants
It's been almost 6 years since the feature was disabled due to instability running GDBM tests in commit 229e23b. The original intent in the commit which introduced the ASAN CI job was described in commit 4e4a36d "Whilst this will detect various dangerous mistakes involving bad memory accesses, it's far more likely to spot if changes create memory leaks." I think it is time to revisit to see after many tooling releases if LeakSanitizer is choking. If so, perhaps it would be better to remove GDBM install as part of this job until whatever triggers failures can be identified and fixed rather than limiting ASAN features in an ASAN CI job.